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LOGISTICS SYSTEM FOR AUTOMATING 
TRANSPORTATION OF GOODS 

This is a division of U.S. patent application Sen No. 
08/128358 entitled "Logistics System for Automating 
Transportation of Goods", filed Sep. 28, 1993, now U.S. Pat 
No. 5,485369. 

BACKGROUND OF THE INVENTION 
The present invention relates generally to computerized 
systems for expediting the shipping of goods in commerce. 
More particularly, the invention relates to a computerized 
logistics system for managing and integrating various 
aspects of order processing, order fulfillment and goods 
transportation and tracking. 

In the past, computerized systems for expediting the 
shipping of goods have fallen into two rather diverse cat- 
egories. At the low cost end of the spectrum have been the 
standalone postage meters and mail manifest systems used 
by small businesses to automate the package weighing and 
carrier manifest printing functions. At the other end of the 
spectrum are the mainframe computer-based systems 
employed by large nationwide mail order merchandisers. At 
both ends of the spectrum the systems have had a number of 
limitations. 

The standalone mail manifesting systems are limited in 
that they are designed to automate only the shipping func- 
tions such as printing mailing label and mailing manifest by 
the shipping clerk or shipping department. As such, the 
conventional standalone system was not integrated with the 
customer order department or with the order fulfillment and 
order packaging departments. Hence, conventional standa- 
lone systems have lacked the ability to take order size, 
package size or time in transit into account when selecting 
the least cost carrier. 

Large mainframe order processing systems are also lim- 
ited. Due to the complexity of mainframe computer archi- 
tecture and associated software systems, it is not practical to 
use these solutions in the small or moderate sized business 
environment Mainframe-based systems often require years 
to develop and to customize for a particular organization's 
needs. Thereafter, large data processing departments are 
needed to maintain the system and keep it operationaL 

The present invention provides a high-performance, cost- 
effective logistics system 'which is readily adaptable to a 
wide variety of different organizations. The system is suit- 
able for deployment on a single, standalone computer or on 
a computerized network comprising many computers. 
Among the advantages of the present system are (1) sub- 
stantial reduction in freight costs; (2) a major increase in 
fulfillment accuracy; (3) convenient order tracking to facili- 
tate warranty, lot and serial number tracking; (4) improved 
customer service; (5) a readily customizable system which 
can be adapted to virtually any shipping operation; (6) a 
robust system having a long useful life; (7) graphical user 
interface screens for easy training and use; and (8) greatly 
reduced implementation costs in a system with increased 
effectiveness. 

As more fully described herein, the logistics management 
system of the invention facilitates the process of shipping 
goods by a shipper having a predefined set of shipping 
requirements via a carrier having a predefined rate structure. 
The system employs a multitasking operating system envi- 
ronment for running a plurality of computer processes 
substantially simultaneously. The environment has a means 
for interprocess communication whereby messages may be 
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passed between the computer processes. A supervisory 
server, running in the operating system environment, pro- 
vides registration services to connect one or more computer 
processes to the interprocess communication mechanism. 
The system further employs at least one rate server, also 
running in the operating system environment, substantially 
simultaneously with the supervisory server. The rate server 
or servers provide access to carrier rate structure data and 
also provide predefined data processing services using the 
carrier rate structure data in response to a predefined set of 
request messages. The predefined data processing services 
include the providing of response messages based at least in 
part on the carrier rate structure data. More specifically, the 
rate server or servers have registration means for commu- 
nicating with the supervisory server to invoke the registra- 
tion services of the supervisory server and thereby establish 
a connection to the interprocess communication means. In 
the presently preferred embodiment there is one rate server 
for each carrier (eg., U.S. Postal Service, Federal Express, 
United Parcel Service, etc.) and these servers are provided 
with a complete knowledge base of all rate structure data and 
shipping rules and regulations per tainin g to that carrier. 

In addition to the supervisory server and one or more rate 
servers, the logistics managements system also includes at 
least one client process running in the operating system 
environment substantially simultaneously with fee supervi- 
sory server and also with the rate server or servers. The 
client process has a user interface for collecting input 
information from a user about a desired operation and for 
providing output information. More specifically, the client 
process also has registration means for communicating with 
the supervisory server, to invoke fee registration services of 
the supervisory server, and thereby establish a connection to 
fee interprocess communication means. The client process 
has a preprogrammed set of rules which are reflective of a 
given shipper's predefined set of shipping requirements. The 
client process also has a processing means for using fee 
preprogrammed set of rules and using at least a portion of 
the input information to issue request messages to one or 
more rate servers and to interpret response messages 
received from the rate servers in order to provide the output 
information. In the presently preferred embodiment fee 
client process is preprogrammed with a knowledge base to 
reflect the shipping organization's rules, regulations and 
practices. In this way, fee client process presents a familiar 
view of day-to-day operations, as seen by fee organization's 
personnel who are responsible for taking orders, packaging 
goods and shipping goods to customers. Because fee some- 
times complex rules and regulations of fee carriers are fully 
handled by fee rate servers, users interacting wife the client 
process do not need to have a full and complete understand- 
ing of fee carrier's rules and regulations in order to properly 
ship goods in a cost-effective and timely manner. 

As more fully set forth herein, fee supervisory server, fee 
rate server or servers and the client process or processes are 
interoperable through fee interprocess communication 
means (a) to receive input information from a user via fee 
user interface of the client process, (b) to use fee input 
information to issue a request message to fee rate server via 
the interprocess communication means, (c) to process fee 
issued request message and thereby cause a response mes- 
sage to be generated by fee rate server, (d) to send fee 
response message to fee client process via fee interprocess 
communication means, and (e) to provide output informa- 
tion based on fee response message. The output information 
can range from simply displaying information on a screen to 
fee user, to printing a mailing label or manifest or to 
updating records in a company database. 



For a more complete understanding of the invention, its 
objects and advantages, reference may be had to the follow- 
ing specification and to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates an example application in which the 
logistics management system of the invention may be imple- 
mented; 

FIG. 2 is an icon view of the plurality of program objects 
which comprise a presently preferred embodiment of the 
logistics management system; 

FIG. 3A is a block diagram depicting a distributed archi- 
tecture embodiment of the invention; 

FIG. 3B is a block diagram illustrating a single, standa- 
lone CPU embodiment of the invention; 

FIGS. 4A-4L, inclusive, represent exemplary user inter- 
face screens of the presently preferred embodiment; 

FIG. 5 is a block diagram illustrating the presently pre- 
ferred mechanism for implementing the client/server 
architecture, illustrating how multiple threads operate in the 
presently preferred embodiment; 

FIG. 6 is a block diagram illustrating the presently pre- 
ferred tree-structured client/server communications mecha- 



DESCRIFTION OF THE PREFERRED 
EMBODIMENT 
The logistics system of the invention serves as a man- 
agement tool for the automated order processing, packaging, 
shipping and transportation of goods. The system is highly 
flexible and adaptable and thus the invention can be imple- 
mented in many forms. Therefore, in order to illustrate the 
principles of the invention an exemplary order processing, 
packaging and shipping operation will be illustrated and 
described. It will be understood that the invention provides 
a collection of building blocks or program objects which can 
be assembled in a variety of different ways to easily con- 
struct a logistics management system for practically any 
application. 

Referring to FIG. 1, an exemplary application is illus- 
trated. In FIG. 1, a networked architecture is illustrated in 
which a plurality of computers are interconnected by a local 
area network bus 20. Of course, the number of computers 
and the network architecture utilized are matters of design 
choke. The invention is not restricted in this regard and will 
operate on systems as small as a single standalone computer 
and as large as a global-wide area network. 

FIG. 1 illustrates a simple system which includes an order 
processing station 22, a packaging station 24 and a shipping 
station 26. The order processing station might ordinarily 
include one or more computer terminals through which 
order entry personnel input a customer's order. The order 
entry terminal may be integrated with a point-of-sale termi- 
nal or cash register or it may be associated with or connected 
with a telephone system through which customer orders are 
placed. In mis regard, while most order entry terminals are 
designed to be operated by an order processing clerk, direct 
order entry by the customer via computerized telecommu- 
nications equipment is also envisioned. 

The order packaging station may also comprise one or 
more computer terminals to which a bar code scanning 
device 28 may be optionally attached. The scanning device 
would be used, for example, to scan the universal product 
code (UPC) of each item as it is picked from the warehouse 
shelves and placed into the shipping container 30. 
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The shipping station 26 similarly may include one or 
more computer terminals to which a scanning device 32, 
electronic scale 34 and mailing label printers 36 may be 
attached. Preferably, the printers are capable of printing the 
necessary shipping documents, bills of lading, manifests and 
so forth, as well as the appropriate package labeling. If 
desired in the alternative, the paclcage label may be pre- 
printed (e.g. at the packing station) and the scanning device 
32 may be used to read the label and thereby automatically 
enter the package identifying number into the system. 

The logistics management system of the invention may be 
implemented in software and run from a variety of different 
computer platforms. Preferably, at least portions of the 
logistics management software are installed and run on each 
of the computer terminals illustrated in FIG. 1. In addition, 
the logistics management system software may also be 
installed and run on other computers attached to the 
network, such as computer 38. As will be more fully 
described below, the logistics management system is also 
capable of interfacing with non-native computer systems, 
e.g., previously existing company database systems, via an 
external processing management system. To illustrate this, 
an external database 40 is depicted in FIG. 1. The database 
may be resident, for example, on a mini-computer or main- 
frame computer used to store company financial records. If 
necessary, the external database system may be connected 
via a gateway 42 to the local area network bus 20. 

Client/Server Architecture 

The presently preferred logistics management system is 
implemented using a client/server architecture and a multi- 
tasking operating system. Although the presently preferred 
system runs under the OS/2 operating system, use of OS/2 
is not a requirement. Any multitasking operating system can 
be used. A multitasking operating system was selected for 
the preferred embodiment because it permits multiple pro- 
cesses (and multiple threads) to run effectively simulta- 
neously. The multitasking operating system thus allows 
multiple programs to run effectively simultaneously and to 
communicate with each other through an interprocess com- 
munications (IPC) mechanism. 

One benefit of the multitasking operating system is that 
the present invention allows the logistics management task 
to be split into multiple pieces. This architecture is quite 
advantageous since it allows updates or changes to be 
effected with respect to part of the system without affecting 
the rest of the system. The client/server architecture derives 
benefit from the multitasking operating system by allowing 
the overall logistics management task to be subdivided along 
functional lines. As will be more fully explained below, the 
presently preferred embodiment places carrier-related 
information, such as shipping rates, shipping rules, time in 
transit information and the like in one or more rate servers. 
These servers are responsible for making all determinations 
regarding how a given carrier's rules and rate structures are 
to be interpreted. The presently preferred embodiment facili- 
tates the particular shipper's requirements, such as order 
taking, order fulfillment, inventory control and the like, in 
one or more client applications. These client applications 
may be customized to conform quite closely to a given 
shipper's operation. These client applications call upon the 
necessary rate servers, as needed, for the appropriate ship- 
ping rates and shipping requirements of the selected carrier. 

The multitasking operating system and the client/server 
architecture of the preferred embodiment comprises the 
logical structure of the logistics management system. The 
physical structure, Lc, how many computers are used and 



how those computers are interconnected, can vary widely 
and still implement the above-described logical client/server 
architecture. More specifically, the preferred embodiment is 
constructed to support distributed applications in which 
different pieces of the total client/server structure are run on 
multiple machines interconnected together via a network. In 
general, there is no limitation on how the respective client/ 
server components are to be distributed across the network. 
Thus, far example, in the system illustrated in FIG. 1, any of 
the computer terminals associated with stations 22, 24 and 
26, as well as computer 38, may host one or more client 
applications and one or more server applications. 

The present invention uses a plurality of program building 
blocks or program objects, each having a specific function 
within the overall client/server architecture. The building 
blocks or program objects which make up the presently 
preferred embodiment are illustrated collectively in FIG. 2: 
FIG. 2 is illustrated in the form of a window or folder SO 
containing a plurality of icons, each representing one of the 
program objects which make up the preferred embodiment 
A brief description of each of these objects is presented 
below. Further details of the manner in which these objects 
communicate with one another and further details of the 
objects construction will be presented thereafter. 

The Presently Preferred Program Objects 

The presently preferred program objects are described in 
Table I below. Broadly speaking, these objects can be 
classified as being client objects or server objects. For 
example, the objects bearing the designation "server" or 
"manager" function as server objects. The objects desig- 
nated as "client" or "administration" (admin) function as 
client objects. 

More specifically, servers such as rate servers encode the 
knowledge required to answer questions such as how to 
calculate shipment rates or how to band shipments. Thus, 
rate servers provide the knowledge regarding a specific 
carrier's requirements. Typically, rate servers are provided 
with specific details regarding a given shipment's weight or 
the required delivery date by a client application. Also 
typically, rate servers do not have user interface screens. 
Servers simply appear as icons on the user's desktop and 
wait to be asked a question by a client Provided the question 
includes the right details, the server will men return the 
correct answer to the client Servers can reside anywhere on 
a network, so they may not necessarily be visible as icons on 
a particular user's computer screen. 

Clients are principally responsible for asking specific 
questions of the servers. Clients have responsibility for 
garnering and displaying information. As such, clients usu- 
ally have user interface screens through which a user can 
enter data or input data through an attached scanning device. 

Manager objects are principally responsible for m a n a g ing 
aspects of the logistics management system, such as the 
communication between clients and servers, or communi- 
cation with printers, scanners and the like. Administration 
objects are principally responsible for providing a user 
interface mechanism whereby the user may edit system 
settings and scripts. 



TABLE I 




Superrisory Server Acts »s a repository for system wide 

information. 

Document Serrer. Manages tbe client requests for 
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printing of those documents. 
Manages the Federal Express rales, 

Manages the UPS rates, carrier rules 
Manages the RPS rates, carrier rules 
Manages the L1X. rates, carrier rules 
Acts as a repository fat 
Manages die client requests for 



Double-clicking this icon will run a 

Allows the user to edit system 

and allows users to send messages to 

Allows the user to create and edit 

Processing Manager. 

Allows the user to configure the 

Federal Express Server settings such 

to close out the manifests. 
Allows the user to configure the UPS 
Server settings such as account 
numbers, rates, discounts and to close 
out the manifests. 

Allows the user to configure the SPS 
numbers, rates, discounts and to close 
Allows the user to configure the 1XL 

A client application which allows the 

A^^^p'^ion whkh^vs the 

of multiple packages per order. 
A client application which allows the 
user to process sh ipm ents comprised 
typically of one package per order. 
Allows the user to create bills of 
lading for LTL Motor Freight 

Allows the user to create and rate bills 
of lading for r.TT, Motor Freight 

Allows the user to configure the 
Document Server with UCC-128 
serial number irArmation and 



In an actual implementation of the system, one supervi- 
sory server and at least one supervisory manager would be 
provided. Specifically, one (and only one) supervisory server 
is provided for the entire network. In addition, one super- 
visory manager is provided far each CPU that will be 
running client or server applications on the network. This is 



7 

illustrated in FIG. 3 A, which depicts a distributed architec- 
ture employing three networked CPUs 102, 104 and 106. As 
illustrated, the supervisory server and one supervisory man- 
ager are running on CPU 104. Supervisory managers are 
also running on CPUs 102 and 106. For illustration purposes 
a UPS rate server object and a UPS rate administration 
object are also running on CPU 102; whereas a shipments 
client and a device manager are running on CPU 106. Thus, 
FIG. 3A represents one possible configuration assembled 
from the collection of presently preferred program objects. 

Although multiple CPU, distributed architecture installa- 
tions represent a powerful configuration, it is possible to 
implement the invention on a single, standalone, GPU. This 
is illustrated in FIG. 3B, in which a standalone CPU is 
indicated at 108. As illustrated, this simple configuration 
includes a supervisory server and supervisory manager, 
along with any other program objects which may be required 
for the task being performed. Thus, in the example illus- 
trated in FIG. 3B several rate servers and a packages client 
have been illustrated 

Application User Interface 

Referring to FIGS. 4A-4L, the presently preferred user 
interface will now be described. In general, the client/server 
program objects, illustrated as icons in FIG. 2, may each 
have a user interface in the form of a screen or window 
through which the user can enter information, make com- 
mand selections, and look up information. In practice, the 
user interface may vary in appearance and function, as 
dictated by the particular task to be performed. Thus the user 
interface screens illustrated in FIGS. 4A-4L are intended 
merely as examples in accordance with the presently pre- 
ferred embodiment 

Overall Icon View — System Folder 

The presently preferred embodiment places icons for all 
user-selectable program objects in the Logistics Manage- 
ment System folder or window, shown in FIG. 2. In this 
regard, the window shows a sample set of icons for the 
presently preferred system. Each icon is a pointer to a 
seperate client, manager or server object By double-clicking 
on the appropriate icon, its object is started. For example, 
double-clicking on the Shipments Client starts that program 
object running. Typically, once an object is started, it con- 
tinues to run and is able to communicate with other program 
objects via the interprocess communications (IPC) mecha- 

Smpments Client 

Shown in FIG. 4A, the Shipments client accepts user 
input for the routing, rating and documentation of a group of 
packages comprising a shipment. Multiple shipper accounts 
arc allowed and the desired account may by selected from 
the Shipper "drop-box." Similarly, the service is selected 
from the Service box. Alternatively, the service may be set 
to Best Way and the system will choose the least cost carrier 
which meets the transit time requirements indicated in the 

The operator types or scans the Reference # (such as order 
#, pick ticket #,...) and the system may be set to look up 
the associated information from one or more local and 
remote sources such as databases and mainframe or mini- 
computer terminal sessions. The upper left quadrant of the 
screen is to record information for the shipment as a whole. 

The lower left quadrant is used to record specific infor- 
mation for each package in the shipment In all client data 
entry screens there are several special data entry provisions. 
Any field which has an ellipsis (...) at its right edge has 



additional related fields of data available to be "examined" 
or edited by touching the F10 key or clicking the Examine 
icon. Apopup window with the associated fields is displayed 
for the user. In addition, most fields may be set up to 
"browse" available valid entries. They may browse from 
database records or from "hard-coded'' values in scripts. 

The Shipments client and most other clients are capable of 
processing shipments of mixed modes; e.g. small parcel 
ground, small parcel air, LTL motor freight, air freight, and 
TL motor freight 

Packages Client 

Shown in FIG. 4B. the Packages client is designed to 
facilitate the entry and processing of shipments which 
typically consist of single small packages. Although, like 
most other clients, it will handle multiple modes of 
shipment, it is best suited for single piece shipments. If a 
multi-piece shipment is encountered, the user may touch 
CTRL-M or click the Multi button and the shipment is 
accomodated. 

Script Administration 

The Script Administration object, shown in FIG. 4C, 
allows the creation and editing of scripts for the modification 
of default behavior of the clients. A script may be triggered 
in various ways, such as upon the changing of the contents 
of virtually any field, upon the pressing or clicking of the 
function buttons on the client screen, upon the opening or 
closing of the client, and so on. In the illustration of FIG. 4C, 
the Shipments client is being operated upon to modify the 
Commitment terms based on the type of Service being used 
by the shipper. 

UPS Rate Adjustments 

Referring to FIG. 4D, the UPS Rate Adjustments program 
object and substantially similar objects for each of the 
carrier rate servers installed on the system, allow the user to 
adjust the discounts and incentive programs extended to the 
shipper by the carrier. Existing discounts may be edited, or 
new incentive programs not yet envisioned by the carrier 
may typically be created by the user within the flexible 
structure of this client type. Adjustments may be qualified by 
destination (either zone, postal code or destination country) 
and by weight range. Adjustments may be calculated as 
percentages or fixed amounts and include or exclude special 
service fees. If desired multiple adjustments may be created 
and put into effect 

Serial Port 2 Configuration 

The Serial Port 2 Configuaration screen, shown in FIG. 
4E, is a part of the Device Manager object It allows the 
adjustment of basic serial port setup values. By clicking on 
the "Defaults" button, the default settings appropriate to the 
specific attached device are automatically entered. The 
'Test" button provides a facility for sending data to and 
receiving data from the attached device. Additional aspects 
of the Device Manager object are discussed in connection 
with FIGS. 4G-4L, below. 

Document Administration 

The Document Administration object, shown in FIG. 4F, 
allows the user to adjust settings for the UCC-128 standards 
of serialized container marking and Electronic Data Inter- 
change. It allows the user to load and store consignee names 
and addresses and UCC-128 specific values. It also allows 
the user to edit the database and settings as changes may 
occur. 

Document Server 

The document server, illustrated as one of the icons in 
FIG. 2, allows any client to print almost any type of 



document, including shipping labels, waybills and mani- 
fests. The in formati on needed to print a document is pro- 
cessed through a script This allows the data to be brought 
in from any number of sources such as databases, 
mainframes, files or user-entered information from a client 
application. Also, one document format can serve several 
client applications and any particular processing needs a 
user might have. This is quite readily accomplished due to 
the fact that all data is passed through scripts. Thus, for 
example, one user might look up the export information for 
a FedEx international document from a database, while 
another user might wish to band enter this data. Both of these 
tasks can be accomplished by a single document format and 
without the need for custom programming. 
Device Manager Object 

The Device Manager provides a device-independent 
means of interfacing with peripheral devices. Device drivers 
can be added or removed without modifying the software. 
The Device Manager also provides integrated testing tools. 

The Device Manager of the presently preferred embodi- 
ment has the ability to monitor power, through an uninter- 
ruptible power supply connected to the system. If power 
fails, the other applications arc notified, and an orderly 
shutdown of the system will take place. This prevents loss or 
corruption of data by sudden power outage or by subsequent 
failure of battery power, once the reserves of the uninter- 
ruptible power supply have been depleted. The monitoring 
service provided by the Device Manager can shut down 
multiple machines on a network connected through one 
uninterruptible power supply. 

Referring to FIGS. 4G-4L, additional capabilities of the 
Device Manager object are illustrated. In FIG. 4G the 
communications port COM2 is shown as assigned or con- 
nected to an electronic scale, in this case a scale designated 
Toledo 8213 Scale. The parallel port LIT1 is shown as being 
assigned or connected to a printer, in this case a printer 
designated IBM 2380 Printer. Beneath the printer designa- 
tion mere appears a notation "No stock" which indicates that 
no particular paper stock has yet been designated. 

Double-clicking on the COM2 icon brings up the con- 
figuration screen shown in FIG. 4E. Selecting the purl-down 
menu designated "Device" brings up the device selection 
menu shown in FIG. 4H. Using the device selection menu 
the Toledo 8213 Scale may be selected, as illustrated. 
Thereafter, by returning to the device manager menu of FIG. 
4G, the Toledo 8213 Scale icon may be double-clicked to 
bring up the device settings menu illustrated in FIG. 41 

Alternately, from the device manager menu of FIG. 4G, 
the parallel port LPT1 may be selected (by single-clicking) 
and configured by again accessing the "Device" menu 
option. In mis case, referring to FIG. 41, the IBM 2380 
printer may be selected, as illustrated. Thereafter, the user 
may click "OK" to return to the device manager screen, FIG. 
4G. From the device manager screen the user can double- 
click on the printer icon to bring up the appropriate device 
settings menu (FIG. 4K) for that device. Referring to FIG. 
4K, note the Current Stock states "No stock loaded." If 

desired, the user can change the current stock by clicking on 
the change button. This action brings up the stock selection 

menu of FIG. 4L. 

DETAILED DESCRIPTION OF CLIENT/SERVER 
OBJECTS 

The client/server architecture utilized by the logistics 
management system affords a great deal of flexibility. The 
client and server program objects are designed to work 



independently of one another, communicating with one 
another through a tokenized message handling mechanism 
discussed below. In this way, rate server data and user data 
are s cparatcd from one another. The advantage of this is that 
when a given carrier changes the way rates are handled, the 
affected rate server can be modified (to change the type or 
amount of data stored in mat rate server, for example) 
without affecting the user's data in any way. This separation 
is important since carrier requirements and carrier service 
options may change at any time. 

The presently preferred embodiment implements an inter- 
nal version numbering scheme which provides a mechanism 
to allow client applications to determine what version of a 
server they are communicating with. In so doing, the client 
applications are able to make any necessary adjustments or 
to disconnect from that server if incompatibilities are found. 
This provides greater reliability, since server applications 
are given the ability to handle communications wilh servers 
intelligently. 

Separation between client and server objects also makes 
possible an automatic updating capability whereby a user's 
existing setup information is automatically merged into a 
new installation when an application is updated or rein- 
stalled. This reduces the amount of setup time due to 
reinstallation. 

Each server of the presently preferred embodiment has 
built-in debugging capabilities which allow server transac- 
tions to be displayed on the screen or logged to a file for later 
analysis. The presently preferred rate servers optimize ship- 
ments to minimize cost through the use of shipment pricing 
rules supplied by the carrier. Optimization occurs "live" as 
a shipment is being processed, or, alternatively, at the end of 
the day when all packages shipped are then optimized. The 
rate servers can directly access carrier-supplied data, such as 
Federal Express routing and rate file data. This allows the 
user to load in new rate information as soon as such 
information is provided by the carriers. In addition, the rate 
servers of the presently preferred embodiment have the 
ability to rate and process a package, but to withhold it from 
the manifest until notified to do so. This allows "pack and 
hold" or future shipping. This is important in an automated 
system where a package may be processed upstream, but not 
placed on the manifest until it reaches the shipping dock. 

In the presently preferred embodiment client applications 
have editable bar code templates, to allow data to be entered 
via a barcode scanner. Because the templates are editable, 
they can be added to, deleted from or modified by the user 
without the need for additional programming. Clients can 
also process in "batch" mode, reading data from a source 
and sending that data to the appropriate rate servers for 
processing. The sources for data can include databases, files 
or direct connection to a host computer via serial or network 
connection. 

As stated above, the presently preferred embodiment uses 
a multitasking operating system which supports the process- 
ing of multiple processes or multiple threads effectively 
simultaneously. This allows client applications and server 
applications to operate effectively concurrently. To illustrate 
how multiple threads operate in the presently preferred 
embodiment refer to FIG. S. In FIG. 5, the left-most box 
designated main thread 120 represents the starting point 
Main thread 120 is launched by the operating system. One 
of the functions of main thread 120 is to perform or control 
the performance of the operating system routines illustrated 
in FIG. 5 by loop 122. When a server is started under the 
operating system the main thread launches a server thread, 



as represented by launch thread arrow 124. The server thread 
is represented by box 126. In the preferred embodiment the 
server thread performs the necessary initialization routines 
128 and then enters a loop or state 130 where it waits for a 
client to initiate a connection request When such a request 
is received the server thread launches a client thread, 
depicted in FIG. 5 by launch thread arrow 132. The client 
thread is depicted by block 134 in FIG. 5. It is responsible 
for handling the client's request Once the client thread is 
launched by the server thread, the server thread returns to its 
wait for client loop or state 130, whereby the server thread 
is men able to launch additional client threads upon demand. 
Thus in the preferred embodiment, each server mat is 
running will include a main thread and a server thread. 
Client threads are generated on an as needed basis. There is 
one client thread for each currently connected client 

Communication between client and server, whereby 
requests are passed to the server and responses passed back 
to the clients, may be accomplished in a variety of different 
ways. In general, the methods of communicating between 
multiple processes running on the same CPU include shared 
memory, semaphores, pipes, queues and signals. The meth- 
ods of communicating between multiple processes running 
on different CPUs (distributed architecture) include mecha- 
nisms such as NETBIOS, named pipes, sockets and mail 
slots. Collectively all of these methods of communicating 
between multiple processes form part of the interprocess 
communication (IPC) mechanism. Not all multitasking 
operating systems provide each of these IPC mechanisms. 
The presently preferred embodiment runs under the OS/2 
operating system and uses LAN Server to provide operating 
system support for a distributed application architecture over 
a network. The presently preferred embodiment uses named 
pipes as the IPC mechanism. 

Named pipes allow one process to communicate with 
another process as follows. The client process first requests 
a named pipe connection to a server process. Once this 
connection is made, there is little distinction between the 
client process and the server process, since either can 
communicate with the other. One advantage of using the 
named pipe IPC mechanism is that the client process 
machine does not have to be running under the same 
operating system as the server process. All that is required 
is that the operating system platform on which the client 
process is running will support named pipes. Thus, a client 
process running under MS-DOS, or under MS-DOS with 
windows, for example, could establish communication with 
a server process running under the presently preferred OS/2 
system, provided named pipe communication is supported. 
Essentially, under a named pipe communications scheme, . 
the server process is known by a pipe name. Programs 
wishing to connect to that server will use the pipe name, in 
a fashion similar to using a file name. For example, pipe 
names may take the form: 



Although the named pipe IPC mechanism permits com- 
munication between any server and any client, the presently 
preferred configuration constrains communication to a tree- 
structured communications scheme illustrated in FIG. 6. 
Referring to FIG. 6, the single supervisory server commu- 
nicates directly with only supervisory managers. In FIG. 6 
the lines of communication are designated by the letter "C" 
at one end and the letter "S" at the other end. These indicate, 



for a given line of communication, which object is the client 
and which object is the server. Thus each of the supervisory 
managers communicates as the client with the supervisory 
server. In a similar fashion, the rate server, label server, 
external processing manager and device manager all com- 
municate as clients with the supervisory managers, as serv- 
ers, likewise, the rate server administration object, the 
shipping client and the device manager administration object 
all communicate as clients with one or more of the objects 
appearing above them in FIG. 6 (namely rate server, label 
server, external processing manager and device manager). 
Thus it will be seen that certain objects function in a dual 
capacity, serving as client objects in some instances and 
serving as server objects in other instances. 

The presently preferred communications scheme permits 
objects to communicate with devices, external databases and 
other computer systems which are not part of the client/ 
server logistics management system. To accommodate this 
certain objects are given the ability to communicate with the 
outside world These objects include the device manager, 
which communicates with hardware devices, such as 
printers, bar code scanners, modems, postal scales and the 
like. Communication with external databases and other 
programs which do not form a part of the client/server 
logistics management system (e.g., accounting software 
packages, spreadsheet programs, operating system utilities 
and the like) are communicated with through the external 
processing manager. 

Because the presently preferred embodiment can be 
implemented in multiple CPU environments (distributed 
architecture), an announcement mechanism is provided in 
order to extend the communications scheme to multiple 
CPUs across a network. The supervisory managers are 
preprogrammed with the ability to send "announcements" 
across the network operating system according to the named 
pipe protocol which has been implemented. Thus, as illus- 
trated in FIG. 6, each of the supervisory managers includes 
a communications pathway designated "announcements" 
through which communications with parts of the system 
operated by different CPUs are sent and received. The 
supervisory managers are not, themselves, responsible for 
coordinating this message passing between objects con- 
trolled by different CPUs. That function is reserved for the 
supervisory server, since the supervisory server occupies the 
unique position of controlling the registration process 
whereby client and server applications are made aware of 
each other in order to communicate. However, in order to 
distribute the announcement function, the supervisory man- 
agers are responsible for providing the actual announcement 
communications, hi mis regard, the supervisory managers 
act as servers, with the supervisory server in this instance, 
acting as the client To illustrate this in FIG. 6, each of the 
supervisory managers is connected to the supervisory server 
by a second line of communication designed "receiver." It 
will be understood that these "receiver" connections repre- 
sent a "reverse" client/server connection, in which the 
supervisory server acts as a client in order to request 
announcement services from the supervisory managers, act- 
ing as announcement servers. 

In summary, FIG. 6 illustrates the preferred IPC connec- 
tions over which client/server communications take place. 
The presently preferred embodiment uses a tokenized mes- 
sage passing scheme in which all data is passed back and 
forth between client and server as ordered pairs of tokens 
and associated data values. The purpose of the token is to 
uniquely identify the data associated with it. Referring to 
Table H in the accompanying Appendix, a sample listing of 



tokens is presented. Reading die columns of Table II from, 
left to light, me left-most column lists the token name; the 
column to its immediate light gives a brief description of the 
nature of the value associated with the token; the next 
right-most column lists the type declaration of the value; and 
the right-most column gives the maximum length of the 
value, where applicable. 

The tokenized message handling scheme is very flexible, 
in mat new tokens can be added at any time to accommodate 
new features, without the need to rewrite all client and server 
data structures. This is in contrast to the conventional fixed 
field data structure used in conventional data communication 
schemes. In the conventional, fixed field data structure 
scheme adding a new data value often requires all program 
modules to be rewritten to accommodate the added data 
field. The tokenized message passing scheme of the present 
invention avoids this problem. If a new data field is required, 
to support a new feature, for example, a new token is created 
and only those objects which make use of the new value will 
need to be reprogrammed to scan for the newly added token. 
All remaining objects simply ignore tokens which are unde- 
fined for mem. 

The presently preferred tokenized message passing 
scheme implements automatic data type conversion. As set 
forth in Table n, the type definitions of all values associated 
with tokens are predefined, thus the tokenized message 
passing scheme has advance knowledge of the data types of 
all values. This allows the tokenized message handling 
scheme to perform all data type conversions, removing the 
need for client and server objects to perform type conver- 
sions. In other words, a server can pass a long word value to 
a client which is expecting a string value. The tokenized 
message handling scheme performs the data conversion 
automatically so that the server does not need to be aware of 
the client's data type requirements and the client does not 
need to be aware of the server's data type requirements. 

External Processing Manager 

In order to allow the client server logistics management 
system to communicate with the outside world, e.g. with 
external data bases or other application programs, the exter- 
nal processing manager is provided The external processing 
manager is, itself, a client of a supervisory manager, as 
illustrated in FIG. 6. The external processing manager, in 
turn, operates as a server to provide external processing 
functions to other clients. In FIG. € the shipping client uses 
the external processing manager for this purpose. 

In the preferred embodiment, the external processing 
manager interfaces with the REXX command interpreter 
supplied with file OS/2 operating system. The external 
processing manager is designed to receive its instructions 
from anASCII file calledascript file. If desired the script file 
can be encrypted to prevent unauthorized access. The script 
file comprises a list of program commands or instructions 
written in the REXX language. If desired, the REXX lan- 
guage command set can be extended to add additional 
commands. This may be done by embedding the additional 
commands in the external processing manager. The external 
processing manager would envoke the REXX interpreter 
and register itself as the source of the additional commands. 
In this way, the REXX interpreter would automatically pass 
control to the external processing manager to handle the 
additional commands. The external processing manager is 
designed to communicate directly with the REXX 



interpreter, passing the script file commands to me REXX 
interpreter and requesting the output of the REXX inter- 
preter to be directed back to the external processing 
manager, where appropriate. In this way, the external pro- 
cessing manager is given access to the operating system and 
to all other application programs running on the operating 
system. This is a very powerful command which allows me 
logistics management system to interface with other appli- 
cations which may not necessarily be designed to integrate 
directly with the logistics management system. For example, 
the external processing manager could use the REXX inter- 
preter to send SQL queries to a database, in order to upload 
information about a customer's account from the accounting 
system software. 

The external processing manager's ability to handle 
scripts provides another powerful feature. Scripts may be 
written for the purpose of modifying the performance of 
other program objects comprising the logistics management 
system. Scripts can be used, for example, change the ship- 
ments client to provide a reminder message to the user in the 
event the user attempts to ship a package without first 
entering the weight of the package. Similarly, a script could 
be written to change the shipments client to supply a 
convenient list of package dimension sizes, allowing the 
operator to quickly fill in the size of a package in the 
appropriate field by simply selecting it from a list. In 
general, the scripting language can be used to provide 
virtually any custom tailoring that a shipper might want to 
implement The REXX language is straightforward and easy 
to use, thus most customizing to meet Hie user's require- 
ments can be done in the field, without the need to access or 
modify the underlying program source code. 

In running a script to modify the performance of a 
program object, the external processing manager uses the 
existing IPC mechanism. Through mis mechanism the exter- 
nal processing manager can request a data item stored by the 
object or it may supply a data value as an input to me data 
object In addition, the external processing manager can 
request mat one or more operations denned for that object to 
be performed. Thus the external processing manager serves 
as an alternate to the normal user interface as a means for 
manipulating data or performing operations. 

From the foregoing it wfll be seen that the present 
invention provides a logistics management system compris- 
ing a plurality of building blocks or client/server objects. 
These objects can be configured to communicate in a variety 
of different ways to accommodate virtually any 
transportation-related logistics application. Thanks to the 
client/server architecture and the support for distributed 
architectures, the overall logistics management task is 
readily subdivided into highly self contained functional 
units. When changes in a given function are required, only 
the object providing the function normally needs to be 
changed. The client/server objects provide further flexibility 
through the external processing manager and scripting 
language, whereby individual objects can be modified to 
provide special features quite readily on an as needed basis. 

While the invention has been described in its presently 
preferred form, it will be understood that the principles of 
the invention may be extended to a wide variety of different 
forms. Accordingly, the preferred embodiment described 
herein should be considered as exemplary of the principles 
of the invention and not as a limitation of the scope of me 
claims. 
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TABLE II 



lb register a program: 

REGISTER PROG_ID 

PROGRAM PROGISTLHra 



•Use this to get a list of AIX programs running m the envrn 
FILENAME is blank, then either the program is not a serw 
you cannot use. For historical purposes, you may use ENU. 
well as ENUM PROGRAM. 
ENUM your current/local machine 

PROGRAM blank if no network use 

MACHINE getrnachinenarne( ) function 

r PROG_JD_ ... id from 

H> PROGISTIH user-friendly 

NAME name of the program FOR 

DISPLAY PURPOSES ONLY!! 
TYPE "server type" mask from 

MACHINE PROGISTIH machine on 

which program is running FOR 
DISPLAY PURPOSES ONLY!! 



rnoie meafc machine names if you want the announcement sent <o specific 

SneTlfyou don't specify MACHINE or if it is blank, (he announcement 

will be sent to all machines currently in the environment. 

ANNOUNCE ANN_ ... from ANNOUNCE -H tag sW 

JD optional string CE_JJAI 

(DATA 

[MACHINE destination machine name siring] 

Miscellaneous 

Use this to close the environment This is harmless and wffl not close 



If QUERY/ENUMMOD1FY SYSNBR 
not yet exist, an entry is automatically < 
defaults: 

Last value (VALUE) 



is automatically added to the number Est with these 



aaU cases, the value passed for TDK-SYSNBR m 
arENUM) and unique within all programs that mi 
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TABLE n-continucd 



VALUE see doc above 

START see doc above 

STOP see doc above 

INCREMENT see doc aborc 

To get me status of all entries in me number 13 

ENUM 

SYSNBR (no value specified) 



SYSNBR see rules above ™ 

VALUE see doc above - optional ka 

START see doc above - optional [°> 

STOP see doc above - opflonal 

INCREMENT see doc above - optonal "J 

If any optional token is not specified, the previous value is not changed. Ti 
can be used to change certain numbers without being required to change 
others. For example, if you add to entry and want to use the defaute for 
STAKE, STOP and INCREMENT but want to specify you own VALUE, y< 



AH of these commands deal with the master list of shippers. Clients can 
access the master list via ENUM. An announcement is sent when any shipper 
informalion of any kind changes. This allows other programs to know when 
they need to do another ENUM - especially if they are storing additional 
shipper information in parallel with this master list Other programs can use 
LOCK and UNLOCK to prevent a shipper from being deleted "out from under, 



follows C rules for a variable 
user-friendly shipper name 
FOR DISPLAY PURPOSES 
ONLY!! 

validity/status of shipper 

shipper abbreviation 

is shipper locked by some 



shipper ID (from ENUM 
SHIPPER) 

unique ID for this shipper 
unique shipper short name 
follows C rules for a variable 
user-friendly shipper name 
FOR DISPLAY PURPOSES 
ONLY!! 

validity/status of shipper 
same/address 
shipper abbreviation 
is shipper locked by some 
program? 
b Information* 

shipper ID (fiomENU 
SHIPPER) 

name/address - optional 
shipper abbreviation - optional st 
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TABLE II-continued 



shipper ID (fromENUM 
SHIPPER) 
a to a program to prevent deleting: 
shipper ID (fromENUM 
SHIPPER) 

PROG_JD_ . . . ID from 
PROGISILH 



a shipper (UNLOCK): 

shipper ID (from ENUM 

SHIPPER) 
; PROG_JD_ ... ID tan 

PROGISIXH 

mar-hire* oc which program 1 
running string blank if no 
network use 

getmachinename( ) function 



user-friendly commitmel 
name FOR DISPLAY 
PURPOSES ONLY!! 
use manifest mode? 
/* default package info 



don't band yet 
ID (see EDXRAEER-H) 
ID (see RATERS) 
payment type (see RATERS) 



recipient address line 2 
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TABLE n-continued 



CODAMOUNT 

CODTYFE 

HAZ 



logical OR of COD 

hazardous milmils? 
signature release? 
direct delivery (Dingle)? 
hold fix delivery? 
Saturday delivery? 
declared value 
•weigh! of dry ice (whole : 



don't band yet 
ID (see FDXRA3ER-H) 
ID (see RATER JI) 
bayment type (see RATER.H) 
payor account number 



COD amount 

logical OR of COD 

hazardous m at e ria ls? 
signature release? 
direct delivery (Dingle)? 
hold for delivery? 
Saturday delivery? 

weight of dry ice (whole lbs) 



date (IDC) 

dimensional weight 

tracking number/COD tracking 



TABLE Il-continued 



(see PRINT section - SERVER-DOC) 



first tracking number 
last tracking number 
first COD tracking number 
last COD tracking number 
first COD return tracking 



signature release authorization 

POWERSHIP plus complaint 
use dimensional rating 
use Express saver 



see FDXRAEERJK for more information on each, element 
M ODIFY 

SHIPPER ID 
[see ENUM SHIPPER section] 
MODIFY 
CONTROL 

SHIPPER ID 
[see ENUM CONTROL section] 
MODIFY 
CONFIG 

[see ENUM CONTROL section] . 
(after END with MANIFEST TRUE, use tins to change item ^formation) 
MODIFY 
ITEM 

MSN package master sequence Ion 



SHIPPER 
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What is claimed is: 

1. A logistics management tool to facilitate the process of 
shipping goods by a shipper via a selected one of a plurality 
of carriers, comprising: 

a plurality of rate servers comprising computer- 
implemented rate storage and calculating means, at 
least one rate server for each of said plurality of 
carriers, at least one of said rate servers having message 
processing means for sending, receiving and handling 
messages; 

at least one of said rate servers having database means for 
Tnafntaining a record of the rates applicable to a given 
one of said carriers and further having an embedded set 
of predefined methods representing the rate computa- 
tion rules of said given one of said carriers; 

at least one client application comprising computer- 
implemented input and output means separate from 
said rate servers and having user interface to permit the 
shipper to interact with said logistics management tool 
in order to process the shipment of goods; 

at least one of said rate servers having a shipper interface 
means for defining a set of operations accessible to said 
client application; the set of operations representing the 
procedure by which the shipper ships goods to thereby 
isolate the set of operations by which a shipper ships 
from the rules by which a carrier transports; 

at least one supervisory server for integrating operations 
of said rate server, and for making said operations 
accessible to said client application, said supervisory 
server having message processing means for sending 
messages to and receiving messages from said rate 
server and said client application and for handling 
messages sent and received based upon a predefined set 
of rules. 

2. The tool of claim 1 further comprising scripting system 
communicating with said client application for modifying at 
least one of said set of operations representing the procedure 
by which the shipper ships goods. 

3. The tool of claim 1 wherein said client application 
comprises a shipments client for rating and documenting a 




group of packages comprising a shipment being processed 
30 by the shipper. 

4. The tool of claim 1 •wherein said client application 
comprises a packages client for rating and documenting a 
single piece of shipment being processed by the shipper. 

5. The tool of claim 2 wherein said scripting system is a 
35 script administration client comprising one of said client 

applications. 

6. The tool of claim 1 wherein said client application 
comprises a carrier rate adjustments client having a user 
interface operable to allow the user to alter the predefined 

40 methods representing the rate computation rules. 

7. The tool of claim 1 further comprising document server 
for providing printing services to said client application. 

8. The tool of claim 7 wherein said printing services 
include printing documents generated to effect shipment 

45 9. The tool of claim 1 wherein said rate server is installed 
on a first computer system and wherein said client applica- 
tion is installed on a second computer system, the first and 
second computer systems being coupled together over a 
network. 

50 10. The tool of claim 1 further comprising external 
processing manager for providing communications services 
to permit said client application to request and receive data 
from an external database not supervised by said supervisory 
server. 

55 11. The tool of claim 10 wherein said logistics manage- 
ment tool is installed under an operating system which 
provides command interpreter facility and wherein said 
external processing manager interfaces with said operating 
system to use said command interpreter facility to provide 

60 said communications services. 

12. The tool of claim 11 wherein said command inter- 
preter facility is responsive to a predefined command set and 
wherein said external processing manager includes means 
integrated with said command interpreter facility for supple- 

65 mailing said predefined command set 
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13. A logistics management tool to facilitate the process of shipping goods by 
a shipper via a carrier, comprising: 

a rate server comprising computer-implemented rate storage and calculating 
means, said rate server having message processing means for sending, receiving and handling 
messages; 

said rate server having database means for maintaining a record of the rates 
applicable to said carrier and further having an embedded set of predefined methods 
representing the rate computation rules of said carrier; 

at least one client application comprising computer-implemented input and output 
means separate from said rate server and having user interface to permit the shipper to interact 
with said logistics management tool in order to process the shipment of goods; 

said rate server having a shipper interface means for defining a set of operations 
accessible to said client application; the set of operations representing the procedure by which 
the shipper ships goods to thereby isolate the set of operations by which a shipper ships from 
the rules by which said carrier transports; 

at least one supervisory server for integrating operations of said rate server, and 
for making said operations accessible to said client application, said supervisory server having 
message processing means for sending messages to and receiving messages from said rate 
server and said client application and for handling messages sent and received based upon a 
predefined set of rules. 



14. The tool of claim 13 further comprising scripting system communicating with 
said client application for modifying at least one of said set of operations representing the 
procedure by which the shipper ships goods. 



1 5. The tool of claim 1 3 wherein said client application comprises a shipments 
client for rating and documenting a group of packages comprising a shipment being processed 
by the shipper. 



16. The tool of claim 13 wherein said client application comprises a packages 
client for rating and documenting a single piece of shipment being processed by the shipper. 



1 7. The tool of claim 1 4 wherein said scripting system is a script administration 
client comprising one of said client applications. 



18. The tool of claim 1 3 wherein said client application comprises a carrier rate 
adjustments client having a user interface operable to allow the user to alter the predefined 
methods representing the rate computation rules. 



19. The tool of claim 13 further comprising document server for providing 



printing services to said client application. 



20. The tool of claim 19 wherein said printing services include printing 
documents generated to effect shipment. 



21 . The tool of claim 13 wherein said rate server is installed on a first computer 
system and wherein said client application is installed on a second computer system, the first 
and second computer systems being coupled together over a network. 



22. The tool of claim 12 further comprising external processing manager for 
providing communications services to permit said client application to request and receive data 
from an external database not supervised by said supervisory server. 



23. The tool of claim 22 wherein said logistics management tool is installed 
under an operating system which provides command interpreter facility and wherein said 
external processing manager interfaces with said operating system to use said command 
interpreter facility to provide said communications services. 



24. The tool of claim 23 wherein said command interpreter facility is responsive 
to a predefined command set and wherein said external processing manager includes means 
integrated with said command interpreter facility for supplementing said predefined command 



25. The tool of claim 13 wherein said rate server is installed on a first computer 
system and wherein said client application is installed on a second computer system, the first 
and second computer systems communicating over a global-wide area network. 



26. The tool of claim 13, wherein the supervisory server comprises an 
interprocess communication mechanism for passing messages between the rate server and 



the client application. 



27. A logistics management tool to facilitate the process of shipping goods 
by a shipper via a carrier, comprising: 

a rate server, connected to a network, having a set of rules by which the 
carrier transports, and having an accessible server interface defining a message handling 
system for communicating with the rate server; 

a client application, connected to the network, having a set of rules by which a 
shipper ships, and configured to communicate with the rate server via the server interface; 



a supervisory server, connected to the network, for communicating messages 
between the rate server and the client application and thereby isolating the set of rules by 
which a shipper ships from the rules by which the carrier transports. 



28. The tool of claim 27, wherein: 



the client application includes an accessible client interface for 
communicating with the client application; and 



the rate server is configured to communicate with the client application via the 



29. The tool of claim 28, wherein the message handling system comprises: 



at least one predefined request message issued by client application to the 



rate server; and 



at least one predefined response message issued by the rate server to the 



client application. 



30. The tool of claim 28, wherein: 



the predefined request message includes a weight and delivery date for a 



package to be shipped; and 



the predefined response message includes a cost for shipping the package. 



31 . The tool of claim 27, wherein set of rules by which the carrier transports 
comprises a knowledge base of rate structures and shipping rules and regulations pertaining 



32. The tool of claim 27, wherein set of rules by which the shipper ships 
comprises a knowledge base of the shipper's rules, regulations, and practices. 



33. The tool of claim 32, wherein the knowledge base of the shipper's rules, 
regulations, and practices comprises rules for taking orders for goods from customers, 
packaging the goods, and shipping the goods to customers. 



34. The tool of claim 27, wherein the client application further comprises a 
user interface for collecting input information from a user about a desired shipping operation 
and for providing output information. 



35. The tool of claim 27, wherein the supervisory server comprises an 
interprocess communication mechanism for passing messages between the rate server and 
the client application. 



36. The tool of claim 35, wherein the interprocess communication 
mechanism is selected from the group comprising shared memory, semaphores, named 
pipes, queues, signals, netbios, sockets, and mail slots. 



37. The tool of claim 35, further comprising an external processing manager 
for interfacing the logistics management tool with external data bases or other application 



38. The tool of claim 35, further comprising a device manager for interfacing 
the logistics management tool with external peripheral devices. 



39. The tool of claim 35, wherein the client application further comprises a 
document server for printing waybills, shipping labels, shipping manifests. 



40. The tool of claim 35, further comprising a document administration 
object for altering communication standards for the message handling system. 



41 . The tool of claim 27 wherein the rate server is installed on a first computer 
system and wherein the client application is installed on a second computer system, the first and 
second computer systems communicating over a global-wide area network. 



42. A logistics management tool to facilitate the process of shipping goods by 
a shipper via a carrier, comprising: 

a rate server having a record of the rates applicable to said carrier and further 
having an embedded set of predefined methods representing the rate computation rules of said 
carrier, said rate server being connected to a network for sending, receiving and handling 



at least one client application connected to said network and is separately located 
from said rate server on said network, said client application having a user interface to permit 
the shipper to interact with said logistics management tool in order to process the shipment of 



said rate server having a shipper interface for defining a set of operations 
accessible to said client application, the set of operations representing the procedure by which 
the shipper ships goods to thereby isolate the set of operations by which a shipper ships from 
the rules by which said carrier transports; and 

at least one supervisory server for making said operations of said rate server 
accessible to said client application, said supervisory server being connected to said network 
for sending messages to and receiving messages from said rate server and said client 
application and for handling messages sent and received based upon a predefined set of rules. 



43. The tool of claim 42, wherein: 

the client application includes an accessible client interface for 
communicating with the client application; and 

the rate server is configured to communicate with the client application via the 
client interface. 



44. The tool of claim 42, wherein at least one predefined request message 
is issued by client application to the rate server; and 

at least one predefined response message issued by the rate server to the 
client application, the predefined request message includes a weight and delivery date for a 
package to be shipped; and the predefined response message includes a cost for shipping 



45. The tool of claim 42, wherein the rate server includes a knowledge base 
of rate structures and shipping rules and regulations pertaining to the carrier. 



46. The tool of claim 42, wherein the client application includes a knowledge 
base of the shipper's rules, regulations, and practices. 



47. The tool of claim 46, wherein the knowledge base of the shipper's rules, 
regulations, and practices includes rules for taking orders for goods from customers, 
packaging the goods, and shipping the goods to customers. 



48. The tool of claim 42, wherein the user interface collects input 
information from a user about a desired shipping operation and provides output information. 



49. The tool of claim 42, wherein the supervisory server includes an 
interprocess communication mechanism for passing messages between the rate server and 
the client application. 



50. The tool of claim 49, wherein the interprocess communication 
mechanism is selected from the group comprising shared memory, semaphores, named 



pipes, queues, signals, netbios, sockets, and mail slots. 



51 . The tool of claim 49 further comprising an external processing manager 
for interfacing the logistics management tool with external data bases or other application 



52. The tool of claim 49 further comprising a device manager for interfacing 
the logistics management tool with external peripheral devices. 



53. The tool of claim 49, wherein the client application further includes a 
document server for printing waybills, shipping labels, shipping manifests. 



54. The tool of claim 42 wherein said rate server is installed on a first computer 
system and wherein said client application is installed on a second computer system, the first 
and second computer systems communicating over a global-wide area network. 



55. A logistics management method for facilitating the process of shipping 
go ods by a shipper via a carrier, said shipper having a computer-implemented client application 
that has access to a network and which is related to shipping said goods, said client application 
having a set of rules by which the shipper ships, said method comprising the steps of: 

providing a rate server having a set of rules by which the carrier transports in 
order to determine data related to shipping the goods; 

providing access to said rate server to data on said network from the client 
application such that said rate server is separately located from said client application on said 



communicating the determined data from said rate server to said client 
application through a supervisory server connected to said network and thereby isolating the 
set of rules by which the shipper ships from the rules by which the carrier transports. 



56. The method of claim 55 further comprising the step of: 
communicating the determined data to the client application through an 



accessible client interface. 



57. The method of claim 55 further comprising the steps of: 

issuing a request message by the client application to the rate server; and 

issuing a response message by the rate server to the client application. 



58. The method of claim 57, wherein: 

the predefined request message includes a weight and delivery date for a 



package to be shipped; and 



the predefined response message includes a cost for shipping the package. 



59. The method of claim 55 further comprising the step of: 
providing the rate server with a knowledge base of rate structures and 



shipping rules and regulations pertaining to the carrier. 



60. The method of claim 55 further comprising the step of: 

providing the client application with a knowledge base of the shipper's rules, 



regulations, and practices. 



61 . The method of claim 60, wherein the knowledge base of the shipper's 
rules, regulations, and practices includes rules for taking orders for goods from customers, 
packaging the goods, and shipping the goods to customers. 



62. The method of claim 55 further comprising the step of: 

collecting via a user interface input information from a user about a desired 



shipping operation. 



63. The method of claim 55 further comprising the step of: 
providing an interprocess communication mechanism for passing messages 
between the rate server and the client application. 



64. The method of claim 63, wherein the interprocess communication 
mechanism is selected from the group comprising shared memory, semaphores, named 



pipes, queues, signals, netbios, sockets, and mail slots. 



65. The method of claim 63 further comprising the step of: 
providing an external processing manager for interfacing the logistics 
management tool with external data bases or other application programs. 



66. The method of claim 63 further comprising the step of: 

providing a device manager for interfacing the logistics management tool with 



external peripheral devices. 



67. The method of claim 63 further comprising the step of: 

providing the client application with a document server for printing waybills, 



shipping labels, shipping manifests. 



68. The method of claim 55 further comprising the steps of: 

installing the rate server on a first computer system, with the client application 

being on a second computer system; and 

providing the determined data of the rate server to the client application over a 

global-wide area network. 



69. A computer storage medium storing computer-executable instructions for 
performing the method of Claim 55. 



70. A computer-controlled apparatus configured to perform the method of 



□ 



m 





i mi o; 



i 
> 



S3 



£3 



O QJ 



CO < 



: cn i- 
o o> 
- 1- co 



to 



2* +J QJ 

— in ct> 

•r- AS 

si 



U I— 



□ 



w o 
? 6 

s □ 



m. 




1 1,1 

O. Ol HI 
□ □□ 



5i 5 
5 £ > § 

> o 

• T N 
u O O X 

* □□□ 



-i 



a 



3 S 



l 1 

E .© 



C0| 



5 § 



S f S 1 1 

* I °- 



UQ 



U □ 



□ □ 



o S 

2 I 



□ □ 



; <->i 



® o > 

I N 



«- w o» » 

If 



1 — 1 




c/5 



1 § 

o E 

O 3 



E 
< 



b 

tar 



8 £ 

1 



EE 




O 
O 



6 

3 
1 

E 



Q. 

XI 



St 



E 



GO 
CM 



O 
U 



1 



2 2 



E 

3 

E 
c 
2 



L 




0 « 

VJ 0> 



a c 

O M 

5 



0) g 

=8 



0> 

o 
c 
o 



o 



o 

o 

en 
to 

CVI 
00 

o 

|2 



i 



to 



1M 



ro o 



Z\ 99 

V 



l- 

Q_ 



V 



0 



E 

en 

a> 
o 



O 
O 
(/> 

ro 
cvi 
oo 

o 




"a> 

I 1 



O 



UJ 






i 



c 



CO 

<D 
O 



•SI 



0) 

c 



O 
00 

8 



m 




2£ 
o 



o 



O 
O 

O 

t 



■3) 
o 
c 
o 
O 



O 



IE 



1 

"5 
O *- 



0> 

_ JQ 

■2 o 



CVI 



s to 

cvi ro 

X X 

CVI CM 



& 
S D 0) 

S E o 

<D 



o 
E 

a x 
— UJ 

n 



Mi 

X X 



+- 



a. 
a 



o 



X 

00 



